Columbia Kermit/kermit.zip/newsgroups/misc.20000217-20000824/[e-mail] _Mon Apr 24 13:06:36 2000.msg

Internet Message Format | 2020-01-01 | 7KB

Return-Path: <[e-mail]>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
    by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA06779
    for <[e-mail]>; Mon, 24 Apr 2000 13:06:36 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA00941
    for <[e-mail]>; Mon, 24 Apr 2000 13:06:35 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id MAA19975
    for [e-mail]; Mon, 24 Apr 2000 12:51:07 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: Ishikawa <[e-mail]>
Subject: Re: Parity incorrectly reported, and RTS/CTS problem on Solaris 7 for
Date: Tue, 25 Apr 2000 01:41:29 +0900
Organization: RIMNET InterNetNews site
Message-ID: <[e-mail]>
To: [e-mail]

Frank da Cruz wrote:

> In article <[e-mail]>,
> Ishikawa  <[e-mail]> wrote (of C-Kermit 7.0):
> : First, thank you for the great package.  I asked a few questions
> : concerning the usage of 8 bits byte, and an even parity several weeks ago
> : on linux and after the kind answers I could get kermit going on Debian
> : GNU/linux well.
> :
> Good...
>

Again thank you!

>
> : [1] One cosmetic bug.
> .

    ...

>
> This is not actually a bug.  As far as Kermit protocol is concerned, the
> parity really is "none".  This means it is using all 8 bits of each byte for
> data, and it doesn't have to use single shifts or locking shifts to encode
> bytes whose 8th data bit is 1.  But yes, I agree it might be clearer to list
> something like "none (8E1)" here.  I'll add it to my list.
>

Again, your clarification is appreciated.

>
> : Now a little complicated one.
> : I am not sure if this is a bug or feature.
> :
> : [2] A user expectancy problem.  RTS/CTS is not supported by
> :     pre-compiled binary for Solaris 7 for x86.
> :
> : But kermit doesn't complain if I specify rts/cts flow-control, and
> : SILENTLY ignored my request, so to speak.
> :
> Thanks for the report.  We don't have hands-on access to Solaris x86 (any
> version) here, so never noticed this one.  All our Solaris x86 binaries were
> built at remote sites, where we couldn't experiment with modems, or sent in
> by others.  (Note: we still don't have a Solaris 2.6 x86 binary.)

Well, maybe I can make the solaris 7 for x86 binary later on if you need one
once we figure out what the correct settings of macros should be.

>
> C-Kermit 7.0 for Solaris is built with -DCK_RTSCTS, which tells it to
> include the commands for setting, showing, and using RTS/CTS.  This has been
> true ever since Solaris 2.0.  It happens automatically in ckcdeb.h, because
> STERMIOX is defined, which in turn means that <system/termiox.h> is available,
> which defines the System-V based hardware flow-control API.

Sorry, I didn't dig enough and notice this sysV API.  I was just
reading through the code to find POSIX  RTSCTS handling code which
I think works on linux.

>
> : It simply failed to set RTS/CTS and merrily goes on processing.  Beat me why
> : it did NOT give me any warning about not-supported RTS/CTS or maybe the code
> : forgot to handle the non-supported case since the code to handle CRTSCTS is
> : cluttered with many #ifdef's.)
> :
> That's what makes it work on hundreds of different platforms :-)
>

Yeah, right :-)
I need to insert a few fprintf lines in order to find out if the code I wanted to

execute was really get executed.

>
> The reason you didn't get a warning is that C-Kermit is indeed calling the
> <system/termiox.h> APIs for setting RTS/CTS, and the APIs are not returning
> an error.  (Take a debug log and search for "tthflow".)
>

Hmm... I will look into it. Here is a dumb question. What is the proper way to
obtain debug log? I found the usage of macros, which seemed to be the
debug macros in the source code, but didn't find out how to enable it
from the command line.

>
> : Anyway, after I modified the supplied `makefile' to define
> : POSIX_CRTSCTS (and inserted a few fprintf(stderr,"...") lines just to
> : let me make sure the expected lines to enable RTS/CTS flow control are
> : executed) and recompiled the C-kermit-7 code, I verified that now that
> : the RTS/CTS enable code is executed and the transfer at 115200 bps
> : (8E1) with flow-control of rts/cts works and transfer of wermit binary
> : (about 1.6MB) using packet length of 3999 (default) with D-type packet
> : went well(!).
> :
> Good!  So it seems that the System-V RTS/CTS APIs have stopped working in
> Solaris 8 and a non-backwards-compatible switch as been made to the POSIX

***** this should read solaris7 (since mine is solaris 7), but probably solaris 8

behaves the same.

>
> APIs.  This is a "double ended error": the old API is broken, but it doesn't
> inform the application of any problem.

It looks to be the case.

>
>
> : I have no idea at this moment if solaris 7 for sparc (not x86) should work
> : with this modification, but it should.  If not, maybe we need a different
> : target (solars7x86 against solaris7) just in case. YMMV.
> :
> This, of course, is an important question.  What is the earliest version of
> Solaris that has the POSIX API for RTS/CTS available (and working!)?  What
> is the latest version of Solaris that has the System V API working?  Is there
> a difference between x86 and Sparc versions?
>

I can check 2.5.1 for sparc, 2.4 for x86 if necessary (and solaris 7 for x86 as I

explained above.)

>
> : Here is the patch to makefile (for solaris 7 for x86).
> : I simply inserted -DPOSIX_CRTSCTS.
> : (Is this macro supposed to be automatically defined when one says
> : -DPOSIX? From the comment I found in the code, I don't think so, but
> : just have to ask.)
> :
> No, it is not, and should not be.  You can never assume anything like this.
> To C-Kermit, -DPOSIX means POSIX 1.0, which has nothing whatsoever to say
> about hardware flow control; POSIX OS's implement hardware flow control in
> all sorts of creative and incompatible ways.
>
> I'm cross-posting this reply to the Solaris lists in case anybody there can
> answer the questions above.  Unfortunately, however, the only real test is
> to build C-Kermit both with and without -DPOSIX_CRTSCTS on every Solaris
> platform and test the flow control.
>
> - Frank

Hmm ... tough cases to solve. Come to think of it, the sparc box I have access
has
already used up both ports and I am not sure if I can remove the serial line for
a while
to test kermit (and I need somewhat longer  cross-cables!). We need many
volunteers.

Anyway, again million thanks!

I wonder MS has this kind of quick feedback from none other than the
one of the original authors of the software :-)

Happy Hacking,

Ishikawa